---
layout: docs
page_title: Generate tokens with Vault
description: |-
  Configure the Nomad secrets engine in Vault and retrieve Vault-managed tokens
  for the Nomad ACL system.
products_used:
---

# Generate tokens with Vault

HashiCorp Vault has a secrets engine for generating short-lived Nomad tokens. As
Vault has a number of authentication backends, it could provide a workflow where
a user or orchestration system authenticates using an pre-existing identity
service (LDAP, Okta, Amazon IAM, etc.) in order to obtain a short-lived Nomad
token.

~> HashiCorp Vault is a standalone product with its own set of deployment and
configuration best practices. You should review the [Vault Deployment Guide]
before deploying it in production.

In order to configure Vault's Nomad secrets engine, you will need the following:

- A Nomad cluster with bootstrapped ACL system.

- A management token (You can use the bootstrap token; however, for production
  systems you should use an integration-specific token)

- A set of policies created in Nomad

- An unsealed Vault server running v0.9.3 or later

- For evaluation purposes, a Vault server in "dev" mode can be used.

  ```shell-session
  $ vault server -dev
  ==> Vault server configuration:

                       Cgo: disabled
           Cluster Address: https://127.0.0.1:8201
                Listener 1: tcp (addr: "127.0.0.1:8200", cluster address: "127.0.0.1:8201", tls: "disabled")
                 Log Level: info
                     Mlock: supported: false, enabled: false
          Redirect Address: http://127.0.0.1:8200
                   Storage: inmem
                   Version: Vault v0.8.3
               Version Sha: a393b20cb6d96c73e52eb5af776c892b8107a45d

  ==> WARNING: Dev mode is enabled!

  In this mode, Vault is completely in-memory and unsealed.
  Vault is configured to only have a single unseal key. The root
  token has already been authenticated with the CLI, so you can
  immediately begin using the Vault CLI.

  The only step you need to take is to set the following
  environment variables:

      export VAULT_ADDR='http://127.0.0.1:8200'

  The unseal key and root token are reproduced below in case you
  want to seal/unseal the Vault or play with authentication.

  Unseal Key: YzFfP...
  Root Token: f84b587e-...
  ```

## Configure Nomad secrets engine

Enable the [`nomad`][nomad_backend] secrets backend in Vault:

```shell-session
$ vault secrets enable nomad
Success! Enabled the nomad secrets engine at: nomad/
```

For older versions of Vault, you might need to use the `vault mount` command instead.

```shell-session
$ vault mount nomad
Successfully mounted 'nomad' at 'nomad'!
```

Once you have the Nomad secret backend enabled, configure access with Nomad's address and management token:

```shell-session
$ vault write nomad/config/access \
    address=http://127.0.0.1:4646 \
    token=adf4238a-882b-9ddc-4a9d-5b6758e4159e
Success! Data written to: nomad/config/access
```

Vault secrets engines have the concept of roles, which are configuration units
that group one or more Vault policies to a potential identity attribute, (e.g.
LDAP Group membership). The name of the role is specified on the path, while the
mapping to policies is done by naming them in a comma separated list, for
example:

```shell-session
$ vault write nomad/role/role-name policies=policyone,policytwo
Success! Data written to: nomad/role/role-name
```

Similarly, to create management tokens, or global tokens:

```shell-session
$ vault write nomad/role/role-name type=management global=true
Success! Data written to: nomad/role/role-name
```

## Create Vault policy

Create a Vault policy to allow different identities to get tokens associated
with a particular role:

```shell-session
$ cat << EOF | vault policy write nomad-user-policy -
path "nomad/creds/role-name" {
  capabilities = ["read"]
}
EOF
Policy 'nomad-user-policy' written.
```

If you have an existing authentication backend (like LDAP), follow the relevant
instructions to create a role available on the [Authentication backends
page](/vault/docs/auth). Otherwise, for testing
purposes, a Vault token can be generated associated with the policy:

```shell-session
$ vault token create -policy=nomad-user-policy
Key             Value
---             -----
token           deedfa83-99b5-34a1-278d-e8fb76809a5b
token_accessor  fd185371-7d80-8011-4f45-1bb3af2c2733
token_duration  768h0m0s
token_renewable true
token_policies  [default nomad-user-policy]
```

## Obtain and test Nomad token

Finally obtain a Nomad Token using the existing Vault Token:

```shell-session
$ vault read nomad/creds/role-name
Key             Value
---             -----
lease_id        nomad/creds/role-name/6fb22e25-0cd1-b4c9-494e-aba330c317b9
lease_duration  768h0m0s
lease_renewable true
accessor_id     10b8fb49-7024-2126-8683-ab355b581db2
secret_id       8898d19c-e5b3-35e4-649e-4153d63fbea9
```

Verify that the token is created correctly in Nomad, looking it up by its
accessor:

```shell-session
$ nomad acl token info 10b8fb49-7024-2126-8683-ab355b581db2
Accessor ID  = 10b8fb49-7024-2126-8683-ab355b581db2
Secret ID    = 8898d19c-e5b3-35e4-649e-4153d63fbea9
Name         = Vault test root 1507307164169530060
Type         = management
Global       = true
Policies     = n/a
Create Time  = 2017-10-06 16:26:04.170633207 +0000 UTC
Create Index = 228
Modify Index = 228
```

Any user or process with access to Vault can now obtain short lived Nomad Tokens
in order to carry out operations, thus centralizing the access to Nomad tokens.

[nomad_backend]: /vault/docs/secrets/nomad
[Vault deployment guide]: /vault/tutorials/day-one-raft/raft-deployment-guide
